home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 299 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.6 KB

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: william.mc@pi.se (William McIlhagga)
  3. Newsgroups: comp.std.c++
  4. Subject: RE: Inherent C++ problem??
  5. Date: 6 Feb 1996 16:08:35 GMT
  6. Organization: ?
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <199602060648.HAA19423@mail.pi.se>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset="us-ascii"
  12. X-Sender: m1717@mail.pi.se (Unverified)
  13. X-Mailer: Windows Eudora Version 1.4.4
  14. X-Lines: 40
  15. Content-Length: 1855
  16. Originator: clamage@taumet
  17.  
  18. Regarding the eliding of copy constructors, John Max Skaller wrote:
  19.  
  20. >        Completely irrelevent. The compiler is permitted to elide
  21. >the copy constructor anyhow. If this changes the observable behaviour
  22. >of you program it's your own fault that your code is not deterministic.
  23.  
  24. There are a few points to note about "determinism":
  25.  
  26. 1) The standard says that an implementation *may* get rid of some copy
  27. constructors; it does not demand it. Thus the indeterminism lies in the fact
  28. that the programmer does not know whether this has happened to their code,
  29. unless the compiler is kind enough to say so (compilers are the strong
  30. silent type, and don't usually tell you anything about what they're thinking)
  31. 2) Removing copy constructors is intended as an optimisation. But
  32. optimisations should never change the meaning of a program - that is, the
  33. program should produce the same results with and without the optimisation.
  34. Clearly, removing "irrelevant" copy constructors is a different kind of
  35. thing altogether. 
  36.  
  37. I think this part of the standard is a little dangerous. I accept that
  38. removing copy constructors is a useful optimisation however (though I
  39. haven't seen any benchmarks to show how big a speedup you get - perhaps
  40. someone could post some to convince us all that it's worthwhile). There are
  41. a few things that might improve the situation:
  42.  
  43. 1) if an implemention removes a copy constructor, the standard should demand
  44. that it issues a warning message (if the user desires...). Though I guess
  45. most people will turn this warning off after a couple of hours, so maybe
  46. that's not so smart.
  47. 2) the standard should include some specified way of switching off the
  48. removal of copy constructors. If it's in the standard then it's
  49. transportable, so no problems there. Perhaps some ugly #pragma or something?
  50.  
  51.  
  52. Cheers,
  53.  
  54. William McIlhagga
  55. william.mc@pi.se
  56.  
  57.  
  58. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  59.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  60.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  61. ]
  62.